home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Jan 91 / MacApp.Tech$ 1⁄11⁄91 / 2607-Pascal++-Jan91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.0 KB  |  98 lines  |  [TEXT/GEOL]
  1. Item    9051249                         8-Jan-91        05:35PST
  2.  
  3. From:   POWERUP.ENG                     Power Up Software,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. ------------------------------------------------------------------------------
  8.  
  9. Sub:    Pascal++
  10.  
  11. Attn:   MacApp.Tech$
  12. SentBy: James Plamondon
  13. Subject:   Pascal++
  14. Dear Mr. White,
  15.  
  16. I read with considerable interest your excellent article on Pascal++ in this
  17. month's issue of Frameworks.  I hope that you will forgive my boldness in
  18. offering you my thoughts on it.
  19.  
  20. First, allow me to say that — short of the ideal case, which simply adopts
  21. Eiffel and calls it "Pascal 9x" — I find the proposed extensions to be very
  22. well-considered.  They are more complete than I had expected, and at the same
  23. time, you have clearly resisted the temptation to squeeze in every feature
  24. known to Man.  Well done!
  25.  
  26. That being said, I can rip the proposal apart with a clear conscience, to wit:
  27.  
  28. 1.  2.1.2:  Returning Objects:  "Pascal++ will not support returning objects
  29. by reference…"
  30.  
  31. I think that this is a major mistake.  To quote "The Annotated C++ Reference
  32. Manual" (Ellis & Stroustrup, '90), p. 154, "By far the major use of references
  33. in C++ is for passing arguments and for returning values… in the latter case
  34. references are used to allow function calls on the left side of assignments."
  35.  
  36. Specifically, the return of a reference as a function result is required to
  37. implement subscripting, as described on p. 336-337 (ibid).  Subscripting is an
  38. essential function of any array class.  Arrays are, of course, rather
  39. important in programming; imagine MacApp without TList.
  40.  
  41. Further, as evidenced by the Eiffel Basic Class Library, a good abstract Array
  42. class is essential for any number of other related container classes.
  43.  
  44. It is entirely possible that the implementation of this feature is unfeasible
  45. for reasons of which I am unaware, or that it is simply too costly in terms of
  46. space, speed, or development costs.  But declining to implement this feature
  47. will have VERY SIGNIFICANT EFFECTS on the quality of the libraries that can be
  48. built using Pascal++; the decision not to implement it should, I think, be
  49. reconsidered.
  50.  
  51. By the way, I agree with your decision to exclude reference variables from
  52. Pascal++ (5.4).
  53.  
  54.  
  55. 2.  2.3:  Repeated Inheritance:   "When a class inherits from an ancestor
  56. multiple times through different paths, the class will have separate instances
  57. of each common field."
  58.  
  59. I recognize that this is a very thorny problem.   C++ resolved it the same
  60. way, while Eiffel addressed it the other way — common fields share the same
  61. instance, using renaming to provide separate instances where desired.  I also
  62. am aware that Meyer's gang has had trouble getting their implementation of
  63. Eiffel's mechanism working.  Still, it seems like such a much more elegant
  64. system (given the existence of a renaming mechanism), that I'd love to see
  65. Eiffel's mechanism implemented instead of C++'s.
  66.  
  67.  
  68. 3.  6.4:  Assertions:  "Pascal++ will follow Eiffel's sematics closely."
  69.  
  70. Meyer is currently looking at changing the way pre- and post- conditions are
  71. inherited in Eiffel, by allowing the form…
  72.        require else
  73.                <additional precondition>
  74.        ensure then
  75.                <additional postcondition>
  76. …which would append the current class' conditions to those of the ancestor(s)
  77. in "the right way."  This is a considerable extension to the existing
  78. mechanism, which requires that the pre- and post- conditions of the
  79. parent(s)'s routine be repeated in the source of the child's routine (a
  80. significant source of programming errors).
  81.  
  82.  
  83. I have one other general comment:  I can see why the working name "Pascal++"
  84. was chosen, but I detest it, and would wish that you had chosen almost any
  85. other name.   I would have thought that the name "Pascal 9x," or even "Ninex,"
  86. would have been sufficient.
  87.  
  88. The name "Pascal++"  debases Pascal by associating it with C++, the "George
  89. Bush" of computer languages.  This makes Pascal++ what — the "Dan Quail"
  90. thereof?
  91.  
  92. Shuddering at the implications, I remain
  93.  
  94. Yours,
  95.  
  96. James Plamondon
  97.  
  98.